2067

Structured Editors: A Literature Review

code-playground

{"id":"kbi296ldkx1214btbgluhoher0m4fxic","created":1479519680113,"modified":1480223185974,"collapsed":false,"content":"loadJS('https://da189i1jfloii.cloudfront.net/js/kinvey-html5-sdk-3.2.2.min.js').then(() => {\n  Kinvey.init({\n    appKey: 'kid_SkPgJV6bg',\n    appSecret: '2e899439ee034f69ae1282bde26899d3',\n  });\n  var answersStore = Kinvey.DataStore.collection('answers', Kinvey.DataStoreType.Network);\n  if (!Kinvey.User.getActiveUser()) {\n    Kinvey.User.signup().then(user => window._user = user)\n  }\n  parent.addAnswer = (data) => answersStore.save(data)\n})\n\nclass Submit extends React.Component {\n\tconstructor() {\n  \tsuper()\n    this.state = {\n    \tsubmissions: [{link: '', isMine: false}],\n      contact: '',\n      name: '',\n      loading: false,\n      err: null,\n    }\n  }\n  \n  update(i, news) {\n  \tconst items = this.state.submissions.slice()\n    items[i] = {...items[i], ...news}\n    this.setState({submissions: items})\n  }\n  \n  remove(i) {\n  \tconst submissions = this.state.submissions.slice()\n    submissions.splice(i, 1)\n    this.setState({submissions})\n  }\n\n\tsubmit = () => {\n\t  if (this.state.loading) return\n\t  this.setState({loading: true,err: null})\n  \tparent.addAnswer({\n    \tcontact: this.state.contact,\n      name: this.state.name,\n      submissions: this.state.submissions,\n    }).then(\n    \t() => this.setState({loading: false, submissions: [{\n      \tlink: '', isMine: false,\n      }]}),\n      err => this.setState({loading: false, err: true})\n    )\n  }\n\n\trender() {\n\t\treturn \n    \tKnow of something cool that's not on this list?
\n      hint: to search, press \"/\"
\n    \t{this.state.submissions.map((sub, i) => (\n      \t\n        \t this.update(i, {link: e.target.value})}\n          />\n          \n             this.update(i, {isMine: e.target.checked})}\n            />\n            I made this\n          \n          \n        
\n      ))}\n       this.setState({\n        \tsubmissions: this.state.submissions.concat([{link: '', isMine: false}])\n        })}\n      >Add link\n      \n       this.setState({contact: e.target.value})}\n      />\n       this.setState({name: e.target.value})}\n      />\n      
\n      \n      \t{this.state.loading ?\n        \t'saving...' : 'Submit!'}\n      \n      {this.state.err && 'Failed to save :('}\n    
\n  }\n}\n\n\n\n// @playground-split\n\nlabel {\n  flex: 1;\n  //padding-left: 10px;\n}\n\ninput[type=checkbox] {\n  margin: 0 10px;\n}\n\nbutton {\n  align-self: center;\n  margin-top: 10px;\n}\n\n.link {\n  display: flex;\n  align-items: center;\n  margin-top: 10px;\n}\n\ninput {\n  padding: 5px 10px;\n}\n\n.contacts {\n  display: flex;\n}\n.contact {\n  margin-top: 10px;\n  flex: 1;\n}\n\n\nh3 {\n  align-self: center;\n  font-size: 14px;\n  margin: 0;\n  padding: 0;\n  margin-bottom: 10px;\n}\n\nh1 {\n  align-self: center;\n  font-size: 20px;\n  margin: 0;\n  padding: 0;\n}\n\n.form {\n  font-family: sans-serif;\n  //align-items: center;\n  width: 450px;\n  display: flex;\n  flex-direction: column;\n}","type":"code-playground","editor_collapsed":true}

835

# Stuff coming together

666

Org

:?!: Right now we have structured tools with easy learning curves but low ceilings, and raw text tools with high ceilings but with a learning curve like being punched in the face with a brick wall. There is definitely room to explore in between the two.

:!: Love this quote :D (about excel, etc)

creating source code in linear text files do the equivalent of keeping their accounting books using a CPM Wordstar text editor. We would never dream of handing a customer such error prone tools for manipulating such complicated cross-linked data as source code. If a customer had such data, we would offer a GUI-based data entry system with all sorts of point and click features, extreme data validation, and ability to reuse that data, view it in many ways, and search it by any key.

Common arguments against

You could get most of the benefits in an unstructured editor using clever incremental parsing/type checking techniques that are well understood by now. http://lambda-the-ultimate.org/node/3567

I'm going to stand by my critique. The ergonomics of structured editing is a show stopper for anyone but novices. Anything that puts you into a rigid mode where you have to fix something before continuing is bad in most cases; e.g., consider evil modal dialog boxes. Imagine a word processor that forced you to fix spelling mistakes before typing the next word!

Just use an IDE!

An approach that might work with existing languages is: To use a traditional flat editor (not a structured editor), but show inferred information around the code. I am thinking of visuals that are akin to http://explainshell.com/ but a lot more compact. The inferred information need not be shown always; it could be shown dynamically based on the user's context (current line, current function, etc)

for me good IDE feels like semantic editor. I'm inclined to believe that text based editor can have all the good features of semantic editor and avoid most of the bad ones.

Syntax isn't what's hard

On the surface it sounds interesting, but I don't really buy the idea that programming is terribly limited by the quality of text editors. Even "basic" editors like vim and emacs can almost instantly catch most syntax problems, and IDEs like Eclipse and Visual Studio are great about complaining if you make a mistake. In my experience, these days relatively few problems come from language syntax errors ... most problems come from mistakes in logic, poor systems integration, or incorrect validation of input data. Not sure how Unison will solve those challenges, but to be fair maybe that is out of scope.

My fave real tools that are doing this

custom editor renderer using webgl apparently?

uses standard file organization though

collapsing code zooms it out

does some input restriction - space does nothing, can't add a binop in an object key

uses CodeMirror (or ACE), and so text is still the fundamental construct, but editing is completely controlled so it might as well be full

alt+arrows for navigation between atoms n stuff

cmd+arrow moves an atom around, or for nagivating within an atom

https://www.youtube.com/watch?v=HnZipJOan54

https://github.com/Cirru/stack-editor

Clouditor https://github.com/Cirru/clouditor/

https://github.com/Cirru/cirru-editor

List of toolsy things

Full structured

Partially structured

Functionality of the structured editor

:!: :!: ah, this one is hybrid. statements, method parameters are just plain text :(

Not really

Eco https://github.com/softdevteam/eco

we hoped to make an editor with all the tree goodness of SDE tools, but which would feel like a normal text editor

:!: save format is a tree

Advantages of SDE that I don't really buy

**metadata** add metadata to functions n stuff (we already have this a little bit with `@Annotation`s, but I think the idea here is that the annotation would then duplicate the display of the function code in the documentation. Which sounds awesome :| kindof

basically, there are a lot of things that fall out of rendering the code richly & purposefully, instead of thinking that we have to stick to some ~static plain-text representation

**inline unit tests** Inline unit tests :-1: no points

I mean yes that's cool, but have you seen intellij/xcode? This is not a structured editor thing

"I can create a new test for the current code without creating new classes and files" this also has ~little to do with structured editing. Why is adding files bad? If it's automatic & you don't notice, then it's fine.

**non-code resources inline** Edit & store non-code resources inline :| also a half-point on this one

icons

vector artwork

animation interpolators

hex values for colors

this would all be stored as part of the source & edited inline using the appropriate interface

this doesn't really need a structured editor - there are plugins for atom / brackets that will show images inline (intellij and xcode will do this for you in the gutter), and we have hex values rendered as color swatches in a bunch of different editors / plugins.

*but* the ability to store these images as part of the "code" file is a cool idea, although not too cool. Beacuse if you have a standard place to put the image (e.g. Xcode w/ Assets, or IntelliJ with the `res` directory, this benefit isn't really much of a step up. Yes it'll make tooling easier (you don't have to know the magic directory to look in, etc.)

**parser errors / syntax** The problem" Rather it is that some apparently reasonable programs fail to parse, and the cause of the errors can be obscure, particularly to novice programmers.

:t: I think this is one problem that SDEs help with, but by no means the only one

Editor integrations ++ partial parsing is hard

this is also a little less compelling reason, because lots of editors can handle this reasonably well

**misspellings** Avoiding user errors

misspellings (also something IntelliJ does just fine at catching & fixing)

**parser impl errors** Avoiding Implementation errors

when you have a parser that errors - also not something I think is super interesting / important

**nested block comments** Argument: nested block comments

Ocaml has this just fine....

so this is not a compelling case for "we need a structured editor"

Multiline strings ( :-1: ok, no points for this one - javascript does this fine)

Variable interpolation ( :-1: also no points. see javascript)

kindof partial points for "no need for escaping rules", but not really because who ever things "oh if only string escaping weren't so cumbersome". It's fine

No need to worry about delimiters like `{}` and `()` ( :-1: also solving something that's not a problem.)

Fewer Keystrokes!

Type driven editing reduces keystrokes and cognitive load

Problems with text

objections to source code

it presents many features of program structure poorly, particularly large-scale strcuture

it unnecessarily ties th efundamental design of the language to its human presentation

it privileges on form of a program over all others (and this form is hard to work with the semantic structure)

transaltion messes for alternative visual presentations and storage formats

very high barrier to entry for creating sophisticated new developer tools

Advantages of Text

**against:** Things like the number of spaces between operators can be used for nice stuff like laying out bits of consecutive lines that have parallel meaning so that they line up. Ordering of functions can be chosen so as to tell a narrative. People have grown quite creative in using the tools they have to write expressive code. If you're going to take this away, I expect to see a good reason to believe that it can be replaced by something equally effective.

:t: this feels to me more like a "this is the best we've got so we make do" rather than "this is a really important thing. Yes, maybe people have gotten creative, but that doesn't mean it's not a square peg in a round hole.

list

{"id":"04x07r1az4qogi9rjx2iwd9n2qgyzhrv","created":1480004383449,"modified":1480004383449,"collapsed":true,"content":"\"A plain text editor is just an IDE with no useful features\" :D ","type":"list"}

suuper adaptable

can express all kinds of things, and you only have to learn one editing paradigm / set of commands

text editors are all alike, and so have low barrier of movement between them

plain text is portable

Preserving source code formatting

:?!: this paper argues that you should take care to preserve formatting

I actually want to ditch custom formatting entirely :D long live the pretty printer

the technology factor

textual source code became tightly intertwined with programming language design

the language factor

the concept of human and computer languages are intertwined

source files have a sequential structure, even when the structure has no meaning (e.g. order of members in a class)

fundamental difference: computer languages have a meaning which is separable from the language, and human languages do not

:t: or at least, computer languages have a well-defined and *cleanly representable* independent of

tools factor

Since the structure of the data doesn't reflect the semantics of the code, tools that manipulate source code can cheerfully ignore any levels of abstraction irrelevant to their task

:!: this is really well put. How can I reproduce that? in a graph format that accomodates traditional tools & stuff

it's easy to write programs that manipulate text

people can paste in pseudocode, or code from another language, and incrementally transform it

:!: oooh this will be an important thing to maintain.

TODO allow pasting in blocks of whatever and treating it as e.g. a comment (can do anywhere a statement can go)

Eidola should, in priciple, be at least as convenient and easy to use as a textual programming language

Textual editing gives a feeling of directness and control. There’s basically a one-to-one correspondence between the editing inputs (type the ‘a’ key), and the default rendering of the model in response to those actions (the letter ‘a’ appearing in the editor). Like drawing a picture, painting, or sculpting clay, the user feels like they are creating via direct manipulation, without needing any deep training to get there. This is a good feeling to strive for even if raw textual editing isn’t the medium used.

Manipulating text to write programs might feel very direct, but only for someone who already knows how to type quickly, and who is fluent in understanding the textual representation of programs. And actually, much of text editing in tools like Vim or Emacs is very indirect. One learns a bevy of different key combinations and shortcuts to produce various effects, and it’s only with time that these actions are so committed to muscle memory that use of the editor starts to feel like direct manipulation.

Why SDE?

But none of these reasons are why projectional editing was invented. It was invented because it allows languages to evolve.

:t: hmmmm

Coming up with a standard on-disk representation

creating a standard sounds like it would be crazy hard

Coming up with standards for a structured editor for a language is a highly challenging and vastly non-trivial task. Such a standard would need not only to cover the appearance of all language constructs in all possible contexts, including margins, padding, colors, border thickness, styles of backgrounds etc. but it would also have to describe and formally specify the editing behavior, keystrokes, visual changes in display and so on. Such a specification would probably be more voluminous than the HTML 4.0 specification, because HTML only covers static presentation and does not include complex runtime behaviors exhibited by structured editors.

I think this might be assume more needs to be standardized than would actually be the case though...

A significant pragmatic problem with projectional editing is the fact that there is no generally accepted format for the storage representation.

The Model (generalized format)

each node has a GUID + multiset of edges

schema DSL - define an interesting structure in the graph :?: I dont understand this

projection DSL - describe how a specific graph should be displayed and edited

general projections that could display any graph (text-like, bubble+line, etc) if a language-specific DSL is unavailable

a type checking DSL

:?: hmmm I don't really understand what he means here

extending a structured language is massively easier than a text one

"I wouldn't hate using a system that is totally structured but stores the data back in a source format

Questions for the standardized graph format

So there are a number of formats that do what you are describing, with all sorts of differing semantics. Some questions that arise, and which your simple-and-general format will need to address: * Can nodes be labeled, in addition to their identity? * Are there different types of nodes? * If so, can nodes have more than one type? * Can edges be labeled? * Do edges have identity? * Are there different types of edges? * Are edges directed? * Can an edge's head be the same as its tail? * Must edges only link nodes, or can they link edges? * Can an edge start/end at itself? * Must the graph be connected? * Can there be redundant edges? * If things have types, are types represented in the graph, or external to it? * What are the semantics of the labels? Are they text, typed data, etc.? * Can nodes be used to label things? * Can edges be used to label things? * Can subgraphs be used to label things? * Can subgraphs be used as nodes? * Can nodes have content? * Can nodes contain subgraphs? * If nodes can contain other parts of the graph, are there nesting rules? If so, how are they enforced? * What sort of operations are supported on the graphs? * Assuming that there are operations to visit all nodes/edges, are they stable (e.g. does adding/removing a node cause the order in which other nodes are visited to change)? * Does the storage format cache information about the graph to optimize common operations (and is this information saved?) * Are concurrent operations supported? * Can graphs be merged, unified, extracted, etc.?

Answers on standardized graph format (from jake brownson, not joshondesign)

Nodes w/ identity

Edges w/ start + end at nodes

But maybe edges also have identities...

all semantic meaning is at the "next level" of the graph structure

Invalid syntax?

For example, it should provide editing for XML structured documents in the same way as text editors do as far as the user is concerned. That is, it **should support invalid syntax, incomplete syntax, etc.** while still having all the benefits of projectional editors.

huh, this is something I don't agree with. I wonder what the point is

:?: I would love to ask this person about the "we should allow syntax errors" bit

> That's one thing Unison is trying to fix. Is that actually a problem? If you're never allowed to input incomplete/broken code, then the way you program is very limited. Often I like to start writing a function, get to the point where I realize I need another function, write that one, and come back to the first function. In an editor where only working code can be input, you can't do this style of programming, which almost rules out exploratory programming. You have to more or less know what you're doing from the start.

:!: ah the answer for this is probably type inference (ocaml style) where function types don't have to be declared ahead of time

also allowing return types to be errors (e.g. have an implicit `failwith "incomplete function"` at the end of the function)

From what I can tell - users love freedom and computers hate them. Why else do you think people still stick to text editors ? A plain text editor is probably the most unconstrained environment there is. So, what is the best way to find some sanity in between? If you ask me, I would say that the main way to transform or change programming would be to remove as much constraint as we possibly can from the user. Let me crap all over the place - and you as the environment make sense out of it. That is why we are building Dhi ( http://www.dhi.io ) - An AI Assistant to help you build user interfaces. We are building it in such a way that the user has complete freedom to say whatever he wants to say and we ( perhaps sometimes even with the help of the user! ) plan to make sense of it. THAT is the dream.

I'd say that users like constraints too

immutable data

VIM modes

It may sound counter-intuitive, but if your editor makes it impossible to type incorrect statements, it'll be really hard to learn/use/hack. Play is an important (essential) part of learning. That said, I think there needs to be more experimentation in this area, so I hope you're successful.

:?!: got to show how "play" can happen in a structured editor

Problems w/ past structure editors

To put this last point another way, with static types, you have to make more choices, and you may have to make these choices at a point in time where you’re unsure how to decide, or when the choice feels distracting.

My thought - static (expressive) type systems help encourage you to *think about the types*, which can be really clarifying and lead to much better code

Ok this is really "thoughts about type systems", but I think they can apply to structured editors

A large class of errors are caught, earlier in the development process, closer to the location where they are introduced.

The types guide development and can even write code for you—the programmer ends up with less to specify

One can refactor with greater confidence, since a large class of errors introduced during refactoring will end up as type errors

Static types can ease the mental burden of writing programs, by automatically tracking information the programmer would otherwise have to track mentally in some fashion.

Types serve as documentation for yourself and other programmers and provide a ‘gradient’ that tells you what terms make sense to write.

in my opinion you definitely do not want to limit the user to constructs which already exist. This forces an implementation order - you always have to declare/build up your toolkit first, and then build on that. Using earth as a metaphor (where support is dependency), you can never build any overhangs, to be filled under later.

Awkward input methods

If this video < http://pchiusano.github.io/2015-03-17/unison-update5.html > is an example of this, then yes, it does look annoying and inefficient. Now I'm not sure if I understand exactly what he's doing here, but it looks like something along those lines: rather than inputting what he wants directly via the keyboard, he has to choose a pattern (like variable-operator-variable) from a drop-down list, and then tab between the fields to fill in the pattern. A poor analogy might be the difference between speaking words verbally to form a sentence vs. shuffling through a stack of index cards to find the right words to arrange on a table to form a sentence. The latter would be useful if you were just learning a language, but once you know how to speak it, that would be an enormous waste of time.

:!: yeah that sounds a lot more annoying ; a usability problem

in the ealiest days of structure editors, you had to enter the structure as a top-down tree traversal (e.g. indicate that you are writing a binop, then the op ("*"), then the first el, then the second el)

usual fix for this is to do a hybrid approach, where unstructured text is added and then parsed

and you switch between the two edit modes

a fairly complex framework of visual controls is necessary

But, if I'm being honest, I wouldn't want to edit a program in MPS, using its current editor, and nor do I think programmers will take to it voluntarily: it makes too many simple things complicated.

However, whilst MPS does a good job of hiding its SDE heritage when typing in new text, editing old text has many of the same restrictions as traditional SDE tools.

As far as I can tell, MPS has gradually special-cased some common operations to work normally (i.e. as in a text editor), but many common operations have surprising effects. In some cases, edits which are trivial in a traditional editor require special key-presses and actions in MPS to extract and reorder the tree.

**Awkward user interfaces**. Code browser interfaces tend to look to standard widget sets for representing programs, with the result that they not only display structure poorly, but make changing it extremely awkward. A good system should make coding easier and faster than plain text -- even giving the option of using text where that makes good sense.

wouldn't have a "cursor" where you can add arbitrary characters

how do you respond to invalid input?

how to navigate around the document?

plain-text programming gives people a feeling of directness & control

**Shadowing a more definitive but inherently less structured representation**. Modeling tools attempt to represent a program nicely before it becomes source code; code browsers attempt this after. However, both are always out of sync by a compile cycle or even a design cycle, and always either end up playing catch-up to the changing source code, or smattering it with "GENERATED CODE -- DO NOT EDIT." The basic problem here is that the canonical form of a program is still the source code.

**Poor representation of information**

**Limited language domains**. Most modeling tools and code browsers represent only a subset of the target language, making the graphical system at best a useful supplement to the text. Component-based systems like Java Beans can be more purely graphical and quite wonderful, but are not robust enough to replace languages as we know them now. A component's job is to abstract away all of the complex structure of a full-scale programming language to create very simple pieces a user can connect in very simple ways. This is fine and accomplishes truly wonderful things, but the components still rely on a more robust language as a foundation.

the complexity of making a parse tree interactive

haha "programmers don't spend that much time manipulating programs copared to all the other things they do"

use a declarative language to define transformations

because their transformations took a long time to implement, bogged them down.

I'm planning on having a vim normal mode, where I feel like you can do most stuff just naturally? Maybe that's naiive. Or maybe it will fall out of having a declarative grammar for the language

:t: hmmm interesting to think about

Unfortunately it has a Vim-level difficulty curve and people don't realize how much time they currently waste on syntax mucking. This makes marketing kinda hard, even with a fully operational and well polished implementation. Fun fact: structured editing also works with non-programming structured text, like JSON, HTML and CSS!

**Parse & Pretty print w/o loss**

For those new to this world and wondering why this stuff doesn't seem to exist, one of the biggest problems with projectional editors is handling the translation problem.

How do you reconcile changes in your representation with changes in the underlying code?

Can you reliably parse handwritten code into your AST representation write it back and so on without any loss?

What happens with handwritten styles that maybe don't fit into the projection's way of viewing the world?

What if I know a better way to output the AST than you?

It's also particularly difficult dealing with change over time since there are no true unique identifiers for bits of code.

Actions

some editing methods are common to most projectional editors.

Top-down editing: You select a placeholder (some empty space), type the beginning of the name of the concept you wish to place there, and select the concept you want from an auto-completion menu.

using a keyword, like `function`, and then it completes w/ the structure w/ holes

Bottom-up editing: Like top-down editing, just that you start with a space that is already occupied and select something to augment it. For example, you start with the number 1, and you select a plus (+) operator to get “1+_” (where _ is a placeholder for the right-hand operand).

some things

Special Actions: Some kinds of language concepts (or AST node-types) are associated with special commands or actions for editing. For example, a list can be associated with insertion and deletion operations. These actions can usually be selected from a menu, or can have keyboard shortcuts associated with them.

hmm what would these look like?

I think the basic operations of "move ast node" shoud be sufficient for a ton of things

paredit needs all the specials b/c there's no first-class idea of having an ast node selected. So slurp/barf are needed

Copy and Paste: Copy and paste operations can take entire sub-trees of the AST and copy them to another place in the AST. This is unlike textual copy and paste, which can copy arbitrary text and place it anywhere.

While editing text is **straightforward and consistent** (only some basic operations are needed, such as insert a character, delete a character, move the caret, etc), editing the AST structure on the screen requires learning how to operate on each node of the program.

Moreover, editors that force the user to use menu, toolbars or the mouse during editing are most probably destined to fail. Text editors allow to edit programs using keyboard only and users won’t give up this ability.

MUST have keyboard-only editing

must be able to just use keyboard

keypresses must not be much greater

consistency is important

ordered_list

{"id":"umt8asi61nmxrliys22kiyoe7cxhn2u3","created":1479445124199,"modified":1479445124199,"collapsed":true,"content":"move though structure","type":"ordered_list"}

2 ordered_list

{"id":"f5udhjbmyzx3pd6wviinjz50alkbgasb","created":1479445132767,"modified":1479445132767,"collapsed":true,"content":"add item before/after","type":"ordered_list"}

a "template", such as `int a = 0`, w/ three possible holes `? ? = ?`, and you replace the `?` with something

ordered_list

{"id":"wgf7fzzzqw3qlpy6n5tuovx5xb4srr7e","created":1479445138446,"modified":1479445138446,"collapsed":true,"content":"modify current node","type":"ordered_list"}

ordered_list

{"id":"fbke2qqvybf7akoawtvh9kq32ikke075","created":1479445143247,"modified":1479445143247,"collapsed":true,"content":"remove current node","type":"ordered_list"}

4 ordered_list

{"id":"6vupoxo45n2t77ybxzx1w9x1zyq5ert7","created":1479445146246,"modified":1479445146246,"collapsed":false,"content":"refactor current node","type":"ordered_list"}

change if to while

encapsulate a set of statements into a fucntion body

split function into blocks

copy / paste

context - dependent > the clipboard contents are truncated to the largest appropriate subtree that could be inserted at the current point

:!: also allow selecting a subset of the statements in a block to paste, for example

Fluidity / flow / syntax errors

4 ordered_list

{"id":"61ypzjwlkppuccdzrw9mhiynm08bvyud","created":1479446776367,"modified":1479446776367,"collapsed":false,"content":"Do not restrain the programmer","type":"ordered_list"}

some [1,2] prevent the creation of syntax errors

"This had the effect that simple operations which change the structure of the program became quite complex, e.g. removing a parenthesis and inserting it somewhere else"

:!: will have to address this in my stuff

Wesner Moise gives a probable answer to this in [WesnerM1]: … Such graphical editors won't actually appear much different from text editors; they may even look the same as text editors, with some differences.” Thus structured editors could mimic traditional text editors to provide familiarity but still retain the advantages of structured editing.

"can reduce the number of primitive user input operations (mouse clicks, key strokes)"

"key stroke prediction based on statistics"

"Wrap" a statement in an if

"Unwrap"

create, delete, reorder nodes

"A hundred or so transformations suffice for editing JavaScript"

typeahead for it

"With practice, pruning with the typeahead feels a little like just typing. However, all the "noise" characters, put there just to make the parser happy, like parentheses and curly braces appear automatically. Typeahead adds to the efficiency of editing, reduces keystrokes, and makes Prune more approachable."

they say not having parens reduces keystrokes, but I think that's actually not a super valuable goal

This sounds super similar to the Unisonweb screencasts

consider using machine learning to predict which transformation will come next :+1:

Another interesting aspect of this example is you can imagine the thought process of the author: “I just want the wrapDomEvent function with the arguments in a different order”.

Programmers use this style of reasoning quite a lot, even in typeful languages.

Refactorings like

switching the order of arguments,

pulling a subexpression out into a let binding,

abstracting a subterm into a function parameter,

beta or eta-reducing an expression,

and many other program transformations

can be conceived of without really considering types at all.

More generally, when you **abstract over parts of your implementation**, you aren’t necessarily reasoning primarily in terms of how this will affect types. You may be primarily reasoning in terms of **where you want information to be specified**.

Abstracting over a concrete value being used in a term is a way of altering where that information is specified, and the programmer conceives of it primarily as such.

Yes, moving around where information is specified affects the types of functions along the chain of dependencies, but this is actually less interesting to the programmer and not the focus of their attention.

Advantage: Better errors

No syntax errors or name errors

Type errors are localized - static typing becomes friendly rather than scary

traditional programming is compile, fix compiler errors, repeat

with REPLs we gain some benefits back, where you can have a feedback look, a discussion w/ the env

but then you move to your file and it's ultimately separate -- even if you can do things like "try evaluating this snippet" from your text editor (emacs + slime)

constrain the editing UI to only allow the creation of programs that typecheck

Advantages

What do programmers actually spend their time doing?

adding imports to the code to be able to resolve names

doing google / hoogle searches to find the name / signature of the function you want

looking up & reading docs

compiling, reading type errors, fixing type errors

large-scale refactorings ("add an extra argument to this function")

small-scale refactorings ("make this chunk of code a separate function")

filling in boring chunks of code whose implementations are at least partially specified by the types

like what a theorem prover might be able to automatically deduce

:t: hmm is this really very common?

formatting code

Fewer context switches!!!

:t: I should think more about this

no parser to write

no tracking locations ( :t: not actually true, there are tree locations now)

trivilly ensure well-formedness

can render as stuff other than text

large-scale edits can be described as a set of refactoring combinators rather than manual text munging ( :| IDEs do this already to some extent)

usable by children & newcomers to the language! like bowling lanes with bumpers

:t: I would submit that *synax is not the hard part*

It's not about typing less or syntax

:?!: Ultimately, I have to concur with the people calling out the lack of need; if my sustained average is 80 lines of code per day, I'm not being bottlenecked by my type time, but I am bottlenecked by typing errors that cascade to runtime. I would welcome seeing more modes that simplify specific, necessary-but-error-prone tasks like copy-paste-modify.

this is a super good comment

the structure editor has to be really clearly beneficial for refactoring, reading code

:?!: I hear what you're saying. But I've been programming for 35 years. I've found that getting syntax right is at worst a tiny percentage of my time/energy/brain cost when doing programming. Once out of the newb phase. Once I've fully grokked the language and I've had enough ramp-up that I'm in "the zone" it's nearly effortless to type syntax-perfect code on my 1st attempt. Even getting built-in library calls and macros right, on 1st attempt, becomes nearly effortless, once in that frame of mind. It's the think-design-code-test loop that is the biggest driver on my time/energy/brain cost. Not syntax conformance. Conformance becomes like a musician having played a certain instrument for enough years, you acquire muscle/eye memory for what note requires what finger/body/mouth positions/behaviors, nearly a one-to-one map, autonomous. Do agree that anything that enforces syntax correctness, upfront, is helpful for newbies, especially "forever newbie" use cases, the non-expert users.

structure editors allow more visualizations of the code! which would be a huge "a-ha" for people I think

:?!: a good example of the editing process that structured editors are better for: Try this exercise: change the first line into the second, with the cursor starting at the caret. Do it slowly and pay attention to each key you touch. lineTo((10, 35), (20, 15)) ^ lineTo((20, 15), (10, 35)) Maybe you had to hold Ctrl+Shift and mash the right arrow to select the first tuple, and then Ctrl+X. Or you typed "d2t,", paying attention to the inner comma. Probably between 10 and 20 movements, all over the keyboard. Three or four seconds, and to me feels like using a blunt knife. And yet you are just moving one element down a list. You do it all day with parameters in a function, statements in a block, items in a literal list. Which is why it has a dedicated command in my editor: "Move down" (https://i.imgur.com/wvcduDk.png). It's a single key. Works in all cases mentioned, for all supported formats. I'm not saying a structured editor is for people who forget semicolons. It's for people who have to work with semicolons.

That's a lovely example. I was going to post that I don't like structure editors, but your example is two keystrokes in Emacs: c-m-F and c-m-T -- which I now (after 35+ years) realize is a structure editor. (one of the first things I worked on when I started at PARC was adapting an Emacs clone since I didn't like the Interlisp structure editor. Little did I know!).

yeah! emacs and vim are approximating this, but think if that was the full mode all the time!

someone claiming "Aside from that, years of user-experience research shows that modal editors are worse than the alternative (if you can hit one key, that means you can't type text in that mode; sorry vim-lovers, but it's true)."

I wonder if there actually is research showing this?

and I'm saying with a low-overhead deterministic-optimized editor like vim, and the right person at the keyboard, this can be done very quickly and accurately. and again, to continue your example, the hard part is not getting the syntax correct it's ensuring the resulting visual image -- your example suggests a vectory visual artifact ala OpenGL or SVG, etc. -- has the right shape and position. Syntax is something my brain/eye system just tells me, instantly, RIGHT or WRONG. our brains are great at this. I'm not saying syntax-enforcing keystrokes are a bad thing. I do think there are benefits to having a set of syntax-generic consistent keystrokes, like vim, across all the various syntaxes one has to deal with, day in and day out. If the only thing I ever had to edit was C files or JSON, that's it, nothing else, then yes having a C or JSON-semantic keystroke-restricted inescapable mode (with prompts, wizards, etc.) would be a help. (Which arguably is how all the big fat modern IDEs have evolved towards anyway.) But I'm very aware of the phenomenon where one can gain in the small but lose in the large. Local maxima, etc.

:!: another thing -> having the key strokes be uniform across different languages

which I think they really would be transferrable

> I hear what you're saying. But I've been programming for 35 years. I've found that getting syntax right is at worst a tiny percentage of my time/energy/brain cost when doing programming. I don't want structural editing because I can't remember the syntax of a language. I want it because I want to edit the code more efficiently. I don't know if I'll really be more efficient, but that's nonetheless what I want. People who use more plain editors like Gedit or Notepad++ might scoff at Emacs or Vim users. But if they think that power editor users use them is because they can't write or navigate text, they're really missing the point. The point is to navigate and edit text more efficiently.

Semantic vs Plain text - editing experience http://unisonweb.org/2016-03-16/semantic-vs-text.html#post-start

:-1: don't need to type full identifier names

don't need parenthesis (fine, but make sure it's displayed in a way my mind can parse)

Structure argument - representation / modeling the domain

:?!: "What the programmer thinks is what they see in the editor"

A programmer designing a piece of code thinks in structures: classes, methods, blocks, loops, conditionals, etc. Using a textual program editor they have to codify those syntactically using parenthesis, etc. The compiler then parses the syntactic elements and re-creates the structures in the form of an AST -- the same structures which the programmer originally had in mind.

The term structure(d) editor is often used to describe editors that are cognizant of the underlying data structure that is being edited. I think this terminology is somewhat misleading in that it suggests that text editors are not structured editors. People might say that a text editor is not cognizant of the edited data structure, because the actual meaning is hidden in the user's mind. I think this distinction is wrong, because no matter how clever an editor is, there can always be an extra projection in the user's mind. The editor has no way of knowing what's in the user's mind. According to this view a text editor is a perfectly valid structured editor for the text document data structure.

hmmm

"a text editor is not cognizant of the edited data structure, because the actual meaning is hidden in the users mind"

Actually, I think the reason is that "the text will get parsed", and editing happens on the level of characters, and not on the level of the structured that the compiler will deal with.

Principles

Correctness

preserve syntactic / AST structure correctness

Atomicity

preserve the AST

atom changes that preserve language invariants

Goals that people have for structured editors

fewer keystrokes

I don't think this is super useful

"validate that reducing the keystroke count was possible"

ummm yeah I really think this is a red herring

fewer errors

100%

greater overall efficiency

? how to measure?

[I would add]

better navigation

better understanding / reading of codebase

constrain the editing UI to only allow the creation of programs that typecheck

Fluid typing

mostly talking about how to enter an expression fluidly e.g. `1 + 2 * 3` in left-to-right, without any fanciness

re "A Structure Editor for C#" [18]

programmer is required to change the way they type (`{` etc aren't typed at all, and aren't displayed)

:?!: Our philosophy is that the programmer may type exactly the same code with the textual and structural editor in order to minimize the learning curve and to easily switch between editors

example code is in haskell

Projectional editing requires some getting used to. You can’t just type your code like you’re used to. You need to understand and respect the tree structure.

:!: goal: make sure you can pretty much type like you're used to

First, programmers often get half way through an edit in one part of a file (e.g. starting an assignment expression) and realise they need to define something else earlier in a file. They therefore break off from the initial edit, often leaving the program in a syntactically invalid state, and make textual edits elsewhere, before returning to the initial edit. SDE tools tend to forbid such workflows since they need to keep the program in a syntactically valid state

:t: I think this should still be possible

If you ever done something like selecting 2 + 3 from the expression 2 + 3 * x, you have done just this. SDE tools force edits to be relative to a tree.

:t: when would you do this??

:t: ok, there are definitely things like this that we do, but only because we can occustomed our minds to thinking in this flat state. I think that editing would be *faster* and better in a purely structured world, even though some edits would be impossible

The main problem with structured editing is that it requires programmers to write code in a certain order that is often goes against their "flow;" enforcing a rigid flow is a huge usability negative. Even without structured editing, we see cases where increased flexibility improves flow; e.g. in dynamically typed languages. Unfortunately, improvements in flow often lead to reductions in feedback (e.g. via static typing). I'm in the camp where the programming experience should be considered holistically. The IDE is a part of that experience, and so language design should occur concurrent with IDE design. With some smart incremental compilation magic along with language-specific rendering in the IDE, we can build programming experiences that provide the benefits of structured (and projectional) editing without the flow costs. Or at least, that is the premise of my research :)

I agree that structured and visual editing paradigms have failed. But ultimately all you're saying here is that structure approaches haven't offered enough positive to offset the cost of learning them. That may be true but it would be good to know why. My guess is that the data structures generated by the text of programs is just too varied and complex for any visual representation system to be of use. The programmer is interested in the final structure of their application and every intermediate one. Creating a program to represent those visually should be harder than implementing the application. Multiply that by every application that could exist.

> But ultimately all you're saying here is that structure approaches haven't offered enough positive to offset the cost of learning them. That may be true but it would be good to know why. No, I'm claiming that bad flow, even after you've learned and adapted to a structured paradigm, needs to be solved directly. Even if you can provide really great feedback, the bad flow will still exist and cause inefficiencies not offset by enhanced feedback, which is aimed at an orthogonal set of problems. Edit: a good analogy might be between agility and armor in a tank. You can obviously make the tank more survivable by improving either one, but its overall usage becomes more limited when emphasizing one feature at the expense of the other.

:!: so make sure that flow is not compromised

Navigation

For the editor navigation controls, there are currently just a few actions: up, down, left, right, expand, contract, leftmost, and rightmost. (I’ll add search at some point too, and that’s probably it.)

This action set can efficiently encode any navigation in the editor, and leaning on the existing geometric intuitions the user has works well.

Easy wins here are using the arrow keys to specify these movements, leveraging the existing encoding most users already have well established.

(And also supporting home row hjkl-style navigation is easy too.)

The one arbitrary part of the encoding requiring new learning is the expand and contract actions.

Though these actions are easy to understand, there’s no standardized keyboard input for them.

But since they are somewhat analogous to up and down, a good default might be + and +.

Navigation actions

open path - Opens the currently highlighted node for editing, which brings up the explorer.

The editor is always in one of two modes - editing, or navigation.

When in the navigation mode, the user has access to the navigations actions discussed above.

close - Close the explorer and transition back to navigation mode, replacing the highlighted node with the expression selected in the explorer.

I’m using the word “expression” more generally here, since we should be able to do the same sort of editing whether we are replacing a subterm of a Unison term, or modfying part of a type or type declaration, or editing the name of a symbol.

cancel - Like close, but leave the highlighted expression in its original state.

filter - Manipulate the contents of the explorer, by typing a query to filter down matching results, or by using the arrow keys or mouse to change what item is selected.

Various refactoring actions which are guaranteed to keep the program well-typed. For instance:

Replace the current selection with its evaluated result. Example: 1 + 1 gets replaces in the editor with 2.

Replace the current selection, x, with _ x, wrapped in a blank function call.

Introduce a new binding at the current scope. That is, x becomes let z1923 = _ in x.

Various actions which aren’t guaranteed to keep the program well-typed.

For instance, replacing the current selection f with `f _`, which is only safe if f is a function of some sort.

Or replace the current selection x with x + _, which is only safe if x is a number of some sort.

This ability to search for actions seems to raise the need for a third mode.

Or does it? Proliferation of modes is complicated and makes the UI harder to learn. Better to just co-opt the explorer for this. When the explorer comes up, **applicable replacement expressions as well as actions** will be shown, and filtering will search for both.

The final set

A small number of navigation actions: up, down, left, right, leftmost, rightmost, expand, contract, and (later) search.

A single action, open, for transitioning from navigation mode to editing mode.

A cancel action, for transitioning from editing mode to navigation mode, with no effect.

An accept action, for transitioning from editing mode to navigation mode, with the effect of modifying the current selection. This is used for selecting both actions (like refactorings) and expressions for substitution.

An accept-and-advance action, which might act like an accept, followed by a right movement, followed by an ‘open’.

The other model I’ve experimented with is simply getting rid of parentheses to control editing entirely. Instead, one uses the arrow keys or to navigate, and there are two actions to accept and continue, one indicated by and another indicated by . Say accepts the current completion and advances to the next sibling of the current node, and accepts the current completion and adds a new child to the current node and moves the editing cursor to that.

Alternative Views to "text looking"

deubgging, structure lighlighting, and UML diagramming

structograms

this is wild

last updated: 2012

https://github.com/mthiede/concrete

BUT the author commented on a github issue a day ago, so is still there

Can create custom html+css templates to display a given syntax node. super cool

same editing commands apply

editing keyboard experience seems very different from text editors -- have to first define the "binop" then the first el, then the second.

http://vimeo.com/9164866

InfoQ article https://www.infoq.com/articles/dsl-concrete-editor

ProjecturEd

https://github.com/projectured/projectured

http://projectured.org/

:t: so there's definitely a distinction between "structured editors" and "projectional editors", in that I'd say one is a subset of the other. A structured editor tends to be a projectional editor with only one projection, which tends to closely match the look of a pretty-printed text version of the AST

It's called projectional editor, because it **provides its editing capabilities using bidirectional multistage projections between problem domains.**

fancy

"Priojections" different reversable presentations of the data

:!: Examples of projections:

filtering - it may be used to focus only some parts of the document while the rest is hidden (e.g. show the chapter titles only from a text document, show some elements from an XML document, etc.)

ordering - it may be used to sort the content (e.g. sort the functions in alphabetical order in Java code document, sort the calendar events in chronological order, etc.)

grouping - it may be used to arrange the content into groups (e.g. group the rows of a table according to the value in the cells of the first column, etc.)

text - stylized text similar to word processing documents

table - two dimensional arrangements

tree - collapsible hierarchical drawings

graph - drawings with nodes and edges

117

Visual look / feel

type inference & display

"proportional font" is not something I anticipated liking, but maybe?

General

"I should *not* be required to run in a window system"

hmmm this is not something I super care about supporting...

hotfixing on a production server doesn't have to be done in the new age of containers, etc.

Gui Elements

Super GUI

Math

Tables

Images, Colors, Numbers (a la KA CS)

Joel - the expression problem & tables http://joelburget.com/the-expression-problem-and-tables/

2 ways you want something to be extensible: easily add new cases for a datatype, and easily add new functions over the datatype

OO makes it easy to add `columns` to the table, meaning new cases

but adding functions requires editing each column individually

Functional programming makes it easy to add `rows` to the table, meaning new functions over the datatype

but adding cases requires editing each row individually

So best(?) case would be to have everything together in a table, so that you can add either rows or columns at your fancy?

I mean, either way you're writing the contents of these methods; if you had a column visualization, then either OO or functional would be equally usable, right?

The expression problem is really a layout problem. It’s impossible to write a one-dimensional (plaintext) file such that data and actions are both immediate.

better interface for defining RegExps :+1: this would be awesome

inline docs w/ a rich text editor :+1: sure, although structured editing is not strictly required for this (see moonshine, Eco)

Editing

an SE is more explicit about the language constructs being entered.

ppl don't have to learn the textual syntax in addition to the higher-level representation

don't have to worry about braces, code is formatted automatically

can go pretty minimal

let you refactor a method by breaking it into smaller ones. It should be able to automatically determine parameters & their types.

"you no longer have to decide whether to bundle all your layout code together or to bundle it with the corresponding button instantiation"

:i: ooohhh so this sounds like method expansion? Whe you can say "expand this method to show me the contents in its place"

but this idea is also "see all the code concerning the save button"

so this is like my idea of figuring out all the uses of an observable

"show me the code, in rough execution order, that deals with this variable"

Hoogle-ish "I want this type, given the local variables, what can you do for me"

Viewing

Visually arranging code in new & interesting ways

local variable colorization. assigns a semi-unique color to each variable in a local context

so you can see if two identifiers match up, and you can easily see where something is defined, etc.

:?!: an argument for a "two-paned view" I think the author has made an interesting point, but I would add that "time has come" to, not abandon text tools (which I don't think has worked; I think the trend is going away from Excel to R and python+pandas, in data science etc), but have a hybrid system, where the text representation of the "view" is visible to the programmer all/most of the time. For example: - we either have plain text "LaTeX" editing where we edit out document/source "blindfolded", and only get to see the result when we compile and view the pdf. - we use a WYSIWYG tool like Word (and some WYSIWYG LaTeX editors) where we stick to the view and are scared (sometimes it's impossible) to dig into the text representation - what we need is something like a hyprid, where a "view" line, and a "text" line are interweaved, or "view" on left side, and "text" on right side. And we could edit any of the two ways, and the other should update. I've been thinking along these line for quite a while, and if I get a change I intend to create some kind of system based on that.

2 ordered_list

{"id":"xns1ct4smbs26hxqci1mchu8g8ew8y5r","created":1479446770839,"modified":1479446770839,"collapsed":false,"content":"Focus on the net code (?)","type":"ordered_list"}

don't display the code in a way that's hard to read / understand

4 ordered_list

{"id":"ipzzy7cnt0aqo7pm48pzek7oh093folm","created":1479446801050,"modified":1479446804386,"collapsed":false,"content":"Keep the layout compact","type":"ordered_list"}

make reading & understanding the code smooth

"should be as compact as the plain text representation"

:t: dunno if I'm totally on board, now that screens are pretty big

2 ordered_list

{"id":"onclvgk2ql9i8i0fs1fbfivmrdzsm3n4","created":1479446892158,"modified":1479446892158,"collapsed":false,"content":"Keep common look and feel","type":"ordered_list"}

as similar as possible to widely-used editors

2 ordered_list

{"id":"5walen8i0706k6h25cji6hfmiymtwbzs","created":1479446952061,"modified":1479446952061,"collapsed":false,"content":"Make the layout configurable","type":"ordered_list"}

colors, etc.

easily skinnable

"preserving a team's guidelines becomes a snap"

in fact, I'd say they become irrelevant :P

"an intelligent scrollbar" - sounds like Sublimes 1000 foot view... not super tied to SEs

"breadcrumb" showing the lineage of parent AST constructs

hmm might be interesting? IntelliJ does this for the package path

list

{"id":"25spib0dk4sfyrvsw6pj2teaxs7uxmwp","created":1480004712902,"modified":1480004712902,"collapsed":true,"content":"tabs vs spaces is ridiculous","type":"list"}

"Show me a switch statement **as if** it had been handled with a set of subclasses"

this is a fascinating idea.

e.g. instead of `switch (exp) { case _: case _: case _ }`, you just see `someclass.callAMethod()`?

seems like this would be a lot easier to do in the other direction. Switch cases are more general, and won't always translate cleanly back

"hide all calls to X package"

You want to be able to trace not only program flow but data flow. Consider a program rendered like a flow chart, with parts of it suppressed. Lines show how a particular datum flows through the system, how it gets operated on and modified. Code that is not germane to that flow is temporarily suppressed

show logic as if it were written in a decision table

show me a flow chart of ifs, loops, etc

table view of an enum declaration

show mutations of a vbl

optionally include method names in invocations, e.g `drawCircle( /* x */ point.x, /* y */ point.y, /* radius */ 5)`

:!: yeah! So you can have swift/objc-style verbosity if you want

show me the program with spanish strings instead (i18n). Highlight places where the spanish string is missing

list local variables / classes that are in scope

inline pre/post conditions that can be shown/hidden, and extracted for testing

track debug logging so you can click the log statement & jump to the place it was called (js console does this)

display code colored by age (newer code pink or sth) - you can know age at much finer resolution than just `git blame` level

display declarations in a grid, w/ `type | name | initialization`

"show me a pseudocode version"

variabled-sized parenthesis

display digits grouped by three `1 000 000 000`

show a version of the function under some statically-analyzable circumstances. e.g. "show me only the code that executed when this flag is `true`"

see Kent's "slice-js" http://slides.com/kentcdodds/faster-javascript#/

7 list

{"id":"5om6u6dx1ueodrh82h8p7qm56ndfmbht","created":1480004510467,"modified":1480004510467,"collapsed":false,"content":"don't think \"less syntax is good\"","type":"list"}

Minimal syntax isn't the answer. The more specific the programmer can be the better.

Minimal syntax is seductive because we like the idea of being concise and typing nothing extra. This is all very well and good.

But the solution isn't to remove syntax, but rather make it optional.

If the compiler can figure out what the programmer means without extra parenthesis and semicolons, then great, but let us add it back in if we want clarity.

Make typing our variables optional for when we are hacking, but let us be more strict when we get to production.

:t: I want to show inferred types everywhere, and have a visual distinction between "locked down" types nad "loose" types -- types that I've said should be enforced, and types that are just indicating what the inference engine has decided. Then you can click on a type to lock it down, or lock it to something more restrictive than the inferred type

IDE-level macros

editor-layer macros - fill out a form, or just call something that looks like a function (only with literals probably) and it will gen the code

2 list

{"id":"ys0gmo2u7dblt7zmu0o2wonzyqfpdmo3","created":1480004797013,"modified":1480004797013,"collapsed":false,"content":"let programmers extend the syntax (e.g. macros)","type":"list"}

:t: what do macros look like in a structured editor? idk!

macros!

Thus very concise and expressive shortcuts for long pieces of code could be defined, which could be expanded into longer code sections during the code generation. The difference between such macros and, say, C #define macros is that the structured macros (unlike C macros) would be language-aware, and thus all the type-checking and verification can actually take place. The problem with C macros was exactly the lack of language-awareness – the substitution took place before parsing, at the preprocessing stage. With language-aware macros the substitution takes place after parsing – language constructs are being inserted into the existing AST, thus allowing all checking visitors to run on the final tree. Moreover, the editor’s grammar and type-checking facilities could only allow inserting macro instances at correct places in the tree. This eliminates the problems of text-based macros and preprocessing.

implement macros :+1: :+1:

let programmers implement their own sequence of transformations

make codemods super easy to do

Screenshots

collapsing code zooms it out

structograms

Module systems

good modules

escape from "classpath hell"

the ability to add a new module and *know* it will work without modification & without breaking something else

In Unison, terms are uniquely identified by a nameless hash (more on that in a later post) and don’t live in packages or modules.

:t: I expect they will find that organization is actually a useful thing

In raw text editing, it’s necessary to disambiguate references with explicit imports. Some IDEs will automate this for you, but the model is the same; the presentation of the program must disambiguate user intent, leading to 50 lines of imports at the top of every “file”, where its often arbitrary how codebase is split up into files. In a semantic editor, we can dispense with the ceremony of imports and instead let the user disambiguate at the point of reference. Here’s a very simple proposed interaction: Upon opening a node to edit, we search local scope based on the search query. If the search query starts with "?" we include global scope as well. If the number of matches is too high, we display only the count. Notice that unlike using something like Hoogle “manually”, we don’t have to enter the type, since the editor knows the type of the current edit location and can supply that information for us! Thus, we just focus on specifying whatever metadata we’d like to search by.

:t: "where it is often arbitrary how the codebase is split into files"

Yeah organizing things is actually important I think.

Graph representation

Eidola, on the other hand, starts and ends in the realm of mathematical structure, and these structures are independent of representation. From a traditional point of view, in Eidola the programmer is directly manipulating the parse tree, but a better way to think of it is that an Eidola program's fundamental form is structured in way that makes the distinction between source code and parse tree meaningless.

The kernel allows different interfaces to observe, query, and modify semantic structures. The kernel's responsibility is to manage the structure of a program; the interfaces' responsibility is to represent this information well and make it easy to change and work with. Different interfaces can observe the same element of a program; if one modifies it, all reflect the change immediately through an event mechanism. Thus, Eidola has no single correct or fundamental notation, and a programmer can view the same program through the lens of different representations for different kinds of insight.

We rarely use code to explain code -- ask a programmer to explain their code, and you'll probably get a diagram with some boxes and arrows. The powerful ideas of high-level languages suffer because we have to work with them through a low-level notation system.

Textual source code is an anachronism, and although modern computers are hardly dumb terminals, we still design programming languages as if they were.

If you can treat the reflected code from a programming language like an abstract data structure, why can’t you just keep the source itself in a similarly abstracted data structure? Isn’t the structure of a program more similar to a graph, than a list?

The order in which the declarations are physically stored in the file would become separated from the logical order in which they are presented to the user. Different developers could even have the same code sorted as they want it.

:!: this is a kye thing

2 ways to represent code:

1) a sequence of text characters

2) as a graph, w/ nodes connected by edges

:?!: "I like to think of writing new code as a process that starts with a graph that is embedded in our brain. Why a graph, you may ask? Because we think of things in terms of concepts and relations between these concepts"

If this is the situation, we make a few graph transformations in our head, transforming the high-level conceptual model of what we want to write into a more elaborate though simpler graph representing the code we actually want to write. Finally we convert this graph to text, and type this text on the keyboard.

Imagine you need to implement a function that calculates income tax one needs to pay based on income and expense data given to you as input. At the beginning, you think in term of expenses, deductibles, income tax, etc. This is known as the problem domain. Each of these is an individual concept, and there are connections between them. For example, income raises the tax due, but deductibles reduce it. The mental graph you start with is therefore a description of the problem domain, focused on the particular problem you need to solve. Then, in your mind, you convert this graph into another graph, where the concepts are those of your programming language. For example, you may convert income and expense data into structures stored in arrays, deductibles into Booleans, and tax calculations into arithmetic operations.

So, why does parsing complicate the design of programming languages? Mainly because it makes decisions made in the early stages of defining a language very critical as the language evolves.

However, this illuminates the problem with keywords: new versions of a programming language cannot add new keywords without breaking existing code!

Basically, every new syntax added to a language must be evaluated to see that it does not collide with some syntax that already exist. Although this looks trivial, the huge number of combinations of possible combinations of language constructs makes the task of extending the syntax of a language so very challenging.

What if we didn’t have to do this part? What if we could program using problem domain elements?

:t: umm so I think this is a faulty premise - we construct functions, types, etc, which mean that we can program using problem domain elements. We don't need to invent custom syntax for every domain object

"Projectional editing is therefore the closest you would probably get to transferring your mental graph directly into a graph on the computer."

yeah, again -> does custom syntax really win a lot more for us here than custom objects / types would?

What is a codebase?

a large graph structure

potentially circular

non-code resources (images)

semi-code (XML)

Source code is a lossy representation of the codebase

Very cool but I am afraid this is geek candy that would not fly for mere mortals. When you say next-gen IDE do you mean for a certain class of developers? The problem with these type of development tools is that it moves your brain from thinking in terms that of a human to thinking in a very structured way more attuned to machines. This is a problem with functional programming in general, it is fundamentally anti-human, people don't think functionally but rather procedurally. Full disclosure here, IDE maker so I have skin in this game :)

:!: moving from the way himans think? :D what does that even mean, do we naturally think in strings of code?

No, they didn't. They invented a syntax two milleniums ago, optimized for use-cases of those ages, using alphabets of those times. Thinking in greek symbols is not helping anyone think clearly. It's just more confusion, because now suddenly, i can't type or phrase a relevant question out loud, until i get a greek keyboard and learn the proper pronounciations of the greek alphabet. The notion we should just stick to a notation and conventions optimized for a different era, a different culture, a different alphabet and a different writing tool (paper), is ridiculous. Do NASA scientists calculate speed using knots? Or power using horse power? They do not. Math is to computer science, what classical music is to pop music. A historical relic that stopped having economic and cultural value beyond being a mere status symbol.

:!: hahah actually classical music is awesome

One of the mantras of functional programming is get your data structure right, and everything else falls into place. As an experienced functional programmer, I see this in practice every time I program--even a slightly "wrong" type pollutes the code dramatically. The idea then with structure/tree/semantic editors is two-fold. First, text is obviously the wrong the wrong data structure for programs, so even if people manage to provide fairly good support with the "modern IDE", the effort it takes is staggering. And still details like files, character encodings, god damn tabs vs. spaces, and terminals leak through. One can't help but wonder how much farther they would get were their efforts directed more efficiently. Look at this https://github.com/yinwang0/ydiff for example, blows text diff out of the water. Second the idea is maybe text is the "wrong data structure" for programmers too, not just tool-smiths. I admit there are bunch more psychological/neurological aspects that make the answer less obvious. But I see no reason why not to keep an open mind until a polished tree editor exists for empirical testing. Even if text is in someways better, the improved functionality a tree editor offers could offset that dramatically.

Version control / Semantic Diff

Version Control can do much better (no, not perfect) diffs

Could visualize & display semantic changes in a changelog, much easier to read & understand

fix versioning

**configuration control system** (version control I think?)

Changesets

Joel is implying that using a structured editor would mean you get semantic changesets for free, which is not the case, but they're super cool

I like the wording **semantic changesets**

"language-aware patch theory" http://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory

Storage and Version Control

changes could be stored & registered at the level of mutations

the code being edited could be a database repository on a possibly remote server

could allow several people to update the same code @ the same time

lots of merge conflicts disappear

all code checked in will be at least syntactically correct (and type correct too if that's integrated into your editor system)

:?!: Moreover, the check in process as such, could be replaced in the future by more fine-granular “transactions on code” – literally each change would be registered in the repository as a transaction and one could group changes manually to the desired granularity level, thus grouping changes to larger entities (for example, one day’s work). The change groups could be grouped too (design pattern Composite) to encapsulate features, milestones, products, etc.

reuse the transformations.

It seems like it should be possible to write a version control system that merges streams of transformations instead of textual diffs, potentially reducing the number of merge conflicts.

The real gem in lamdu compared to LT, Subtext,MPS etc is the integrated versioning, IMO. Far too long have we been doing snapshot-based development. I hope this is a language feature and not just an IDE feature, however, so that the evolution of the program is expressed within itself

:!: oooohh integrated versioning! I should check this out more

And there’s a deeper question—what is VCS really “about”? Perhaps VCS is really about several distinct concerns: Supporting concurrent development Maintaining history, for lots of reasons, including auditability Providing commentary on edits, and possibly on groups of edits Having a notion of logically related branches of development

So it seems like the "waterfall effect" of edit propagation would get reeeally out of hand. A single-line change to a function could cause ripples throughout the codebase, and that would happen for *every* edit to that function. Wouldn't that be a bit much?

"Semantic Version Control"

I’ve been really interested in the idea of semantic version control for a while, in which the unit of edits is not text diffs or even tree diffs, but semantic edits that map more directly to programmer intent. So, an edit might be ‘swap the order of these two function parameters’ or ‘rename this function parameter from x to x2’.

Tools around it

ecosystem of tools around code as text

version control

CI / CD (I don't think this would actually be effected?)

diff tools

IDEs

Tools that would need to process a new format

editors

source control

difference vizualizers

... any others?

vim

grep

diff

git diff

could really simplify the implementation of many components

code completion

refactoring

debugging

edit & continue

The thing is, it is easier to make the IDE intelligent if there is no need to constantly round-trip between text and AST. A good example is extracting a method, which would be simpler to implement in comparison with some current implementations, where a lot of effort has to be put into the round-tripping. When some code has to be inserted into the program with a text editor, a major problem is finding the correct place to insert and take care of the formatting. A structured editor takes care of the formatting.

Renaming & refactoring is triviial ( ooh, having scripts be able to trivially do codemods is super enticing)

eliminating the need for a background compiler

:t: but you still need a type checker? which could potentially be expensive

On-Disk Storage

unix says text streams are the ultimate data format

but parsing is a pain

what if we had a standard data format that could communicate some basics - integers, booleans, records

huh sounds kinda like JSON. pretty much has become the de facto serialization format for structured data

Another dirty secret was that the magic internal representation didn't turn out to be necessary. Modern PL implementations can lex, parse and structure tens or even hundreds of thousands of ASCII lines per second. If you want some "special" program representation for a tool, you can just go parse everything into it, do your business, and get out. Take a look at the Inform 7 compiler: Whole-program translation of syntactically wacky ASCII text every time you want to run your game. Happens so fast you don't even notice until the games get really, really, really big. Look at Sparse, and how fast it can do whole-program analysis of the Linux kernel. Etc.

:t: so "you don't really need it", based on the idea that the main draw is saving parse time. I can do better

It may have had the structure available to tools making for famously great refactoring, etc, but the user's experience of editing the code was still textual

:!: great rebuttal :D

For example, turns out that non-ASCII representations are fragile--go figure. Change the language representation slightly, and everything else changes a lot. There's no limping along patching things by hand until the tools catch up, either. All the tools have to change with the representation: flag day. And the tools have to accept old representations, because the representations are hard to upgrade: backward compatibility hell.

:t: hmmm. so what tools would we have, and would they be general enough to accomodate new languages w/o configuration, and have reasonable fallback if we change the language AST structure?

git diff -> yes, I think we could just have a generic tree diffing algorithm, and more "intelligent" algorithms that would be lagnuage aware. But tree diffing would be a good fallback

IDEs - hopefully could be defined generally (w/ the grammar etc) that they could respond to changes in syntax? Or fall back to a generalized tree editor if the code is in a new version of the language that it doesn't support yet?

we have this currently with syntax highlighting -- new js syntax comes out, and the editors highlight all wrong, but it doesn't impede coding much because highlighting is just icing. If we have a structured editor that is unable to handle the structure, then bad things.

:!: so we need to make sure that "releasing a new version of the language won't cause mass breakage in IDEs"

3 list

{"id":"ooobspv5f9i6tw9vrq871ob8kp9f45l0","created":1480004346030,"modified":1480004346030,"collapsed":false,"content":"don't store code as ASCII on disk. do something more interesting than that","type":"list"}

save the structure

store useful metadata, non-code and non-text resources

2 ordered_list

{"id":"qje7pjno0z4q38rstsljpz823i93lof0","created":1479446946709,"modified":1479446946709,"collapsed":false,"content":"Do not introduce new dependencies","type":"ordered_list"}

"should not necessitate changes to the programming language or the way programs are stored"

could have the option of storing source code to plain text files

or the storage format could be standardized (just like a programming language syntax is standardized)

:?!: Beside standardizing programming languages of the future, it will probably make sense to simultaneously standartize the structured storage/representation format for programs in that language.

:?!: This article makes exactly the same mistake that pretty much everyone else suggesting programmer tooling beyond plain text has made: assuming it has to be either or, that if we want more sophisticated tools that use a more complex representation, we have to give up text. The suggestion is a nonstarter. Network effects alone would prevent the world making such a move, and it's a good thing, because the loss wouldn't be just a particular existing tool, **it would be the entire universe of tools that work with text**, that the world has spent decades developing, most of which any individual has never even heard of, let alone thought about how to replace. It's also completely unnecessary. If you want a tool that lets you view and edit your code in a fancy table format, you can write one. All it needs to do is parse the existing source code into whatever internal format it wants and write it out again afterwards. Yes I know the author criticizes parsers, but really, writing reliable parsers has been done often enough to make it clear that it's a solvable problem. And would it not be better to have some of what you're looking for in an actual tool than all of it in an imaginary one?

:!: I'll need to make sure I address this

Source editing http://martinfowler.com/bliki/SourceEditing.html

Definition

Source based programing environments hold the definition of a system in a set of source files which act as both an editable and storage representation of the system definition. These sources are then transformed to an executable representation that actually runs. Source based code is the most familiar form around today in contrast to in contrast to ProjectionalEditing (where I discuss the two in more detail).

Multiple representations of the system

editable representation: what you edit in order to change the system.

storage representation: the persistent record of the system definition.

executable representation: what is executed to make the system run - the executable.

abstract representation: used to manipulate and reason about system definition.

visualization representation: a non-editable view of the system definition.

:!: I'd add: mental representation, tends to have more context, connections, and annotations

:!: "With projectional editing the abstract representation is the is core definition of the system. "

money definition

on: being able to go back to a normal text editor when desired

:t: this could have to do with "serialize to the normal code, so interop"

3 ordered_list

{"id":"2wjlnnqv61e28xhupa4cofeo2du59jug","created":1479446957700,"modified":1479446957700,"collapsed":false,"content":"Leave the choice to the programmer","type":"ordered_list"}

"some programming tasts might be easier to achieve w/ a simple SE, an advanced SE, or a textual editor. Should be able to swap between editors & editor modes"

I also want to disagree with this - I think text should be ditched completely

don't lock people in to your specific tool

Lack of flexibility

hmmm interesting claim

that structured editors, in order to be ideal, would want to relax some strictness constraints to temporarily allow syntactically / semantically incorrect programs?

not sure I agree

"The editor shouldn't stand in the way"

Automatic creation of structured editors

huh, this is a toolkit for creating structured editors

VERY gui, like Visual Basic style. not really my jam?

:!: thinking about a graph editor being a structure editor...

Performance

:?!: It's not a solved problem if your project is gigantic or if you're doing cross-platform development and don't want to or can't use the build system of the IDE or if it's C++. To me solving the problem has a higher bar - you should be able to open a large project for the first time and have usable intelligent editor support within a second. I'm even okay with the results of autocomplete being incorrect (to a degree) if they are fast. I think IDEs make the wrong tradeoffs. They require you to use their build system and insist on parsing all the code in your project before providing anything useful. And guess what none of the IDEs that I tried for C++ provide something as basic as a fuzzy file finder by default. Most don't even have plugins for that and those that do have very bad and slow implementations. For me something like Sublime Text with a few plugins works great. And before anyone goes yada yada about semantic autocompletion and all that - you can get that too at a very cheap cost - look at YouCompleteMe for vim. For project wide searching I find it easier and more reliable to use grep (or git-grep, ag, ST built in search, etc.) than relying on the IDE's find symbol functionality.

dunno if I'm going to address this person's stuff...

Misc "This has been tried before"

This stuff has been done forever, and it's been "the next generation" forever. Things like **separation of structural editing from the language specficness of an AST** while still providing a sane and useful editor are paths that have been tried before. Not that this means people shouldn't try, but as you can see from just these two links, there has been a lot of research and effort put into this area in general. This is an area where **i'd read a lot more than i'd sit down and code**, because a lot of smart people have been this way before. Case and point: Susan Graham (and maybe Tim Wagner), who lead the Harmonia project (and many projects before that), is basically the goto person in the world if you ever wanted to know anything about incremental analysis of programming languages (she also helped write gprof, among other things)

:t: hmm so this is "translating multiple languages to the same AST representation"

NOTE there are bunch of papers that I still have to read (deleted b/c there will be lots of editing)

Readable code!! by Laura https://www.youtube.com/watch?v=B3X_nhJ61Ak

THinks I'm looking forward to

having it be normal / easy to make an editor plugin that changes the rendering of some common pattern / library / etc.

rendering JSX as the layout will be (+aphrodite aware would be so awesome)

rendering react-storybook or react-sandbox stuff on the side

rendering observables operators w/ marble diagrams

also render `TODO` comments better, and allow attaching metadata to the TODO comment do it's structured as well. This would mean that the serialized representation would lose some of that, so it'd be better to have a rich serialization in that context

:i: woah so about poorly-encoded state machines & state errors -> a lot of things where there's something to be initialized, and then we can use some methods or whatever.

But what if we need is to break off all the stuff that's depending on that initialization and put it into a separate class, and have that be a child of the main thing or something. Is that generally what we want?

I know in java classes are **crazy** frictioned, and annoying to set up lots of them. so maybe that's a problem.

157

Categories of things

Table

table

{"id":"r9w9czq0kjj5benwwsif01p863koje1e","created":1480230187693,"modified":1480230187693,"collapsed":true,"content":"","type":"table","tags":[],"table":{"matrix":[["Name","Year last active","Demo","Has \"Gui\" elements","Refactoring","Typed","SDE full/mix/no","Lang","Plugin","Usable"],["Sediment","2015","sediment.io","y : types shown above the function, rich docs displayed on the side","-","y","full","invented","n","C"],["Prune","2015","","n","+","n","full","javascript","n",""],["??","2015","","n","~","n","full","lua","n",""],["East","2009","https://sites.google.com/site/rathereasy/eastwest","n","n","y","full","invented","n","F"],["Makepad","live","makepad.github.io","n : but the zoom to collapse is cool","n","n","full","javascript","n","A"],["Golem","2015","shem.io","y : notebook","~ (can splice in the body of a fn)","y","full","invented","n","A"],["Cirru","live","cirru.org","n","n","n","full?","clojurescript","n","C"],["","","","","","","","","",""],["","","","","","","","","",""]]}}

Full Structured Editors

Blog posts

More interactions

In the explorer, typing a space followed by an operator accepts the current completion and opens a fresh explorer with the operator prefilled. You can see this in the video, where 1 + becomes (+) 1 `_`. In the explorer, typing two spaces accepts the current completion and moves the explorer to the right. You can see this in the video. Typing ‘s’ steps (linking + 1 beta reduction) the selected expression. Typing ‘e’ evaluates the selected expression (to weak head normal form). Global search is now enabled by default in the explorer. In the video, I look up the identity function. Notice that the completions are aware of the admissible type. When we go to fill in the second argument to +, we see the fully saturated version of (+), applied to two arguments, `_` + `_`.

Typing ‘a’ applies a function to the selected expression, so 42 becomes `_ 42`, and the focus moves to the `_`. Typing ‘r’ does one eta-reduction, so x -> f x becomes f. Terms which are ill-typed but which match the search query are displayed in the explorer along with their types (but are unselectable of course). Builtin functions for concatenting strings. Stepping works fine under lambdas. For instance, we can simplify the 1 + 1 in x -> f (1 + 1) to x -> f 2.

:t: feels like these actions are on the super-PL-theory side of things, and might not actually be useful?

About spreadsheets

Spreadsheets have a largely nonsymbolic representation of programs. The only symbolic representation used is the simple expression language, which people can easily learn as it consists only of constants and function application. Of course, every spreadsheet program has some ad hoc language for defining new formula, but that’s outside the usual spreadsheet model and gets used very rarely.

We can think of the spreadsheet as a limited kind of application-building toolkit. It supports a form of interactivity, in that we may select a location for editing, and updates occur in response to these edits (conceptually no different than any other application, be it Photoshop or Twitter). There’s no separate step of ‘running’ the program and we’re encouraged to consider the UI as just a way of viewing a program, rather than a separate artifact produced by a program. See viewing a program as a UI.

The user can easily construct functions that manipulate sequences in an inductive fashion, considering only concrete inputs. For instance, the cell A2 takes the value = A1 * A3 + B$7, and the user drags to extend the definition to build a whole sequence. Of course, a programmer has no trouble generalizing this sort of thing and just writing a step function that uses symbolic inputs, but it requires less learning to do things the spreadsheet way.

Lastly, and this might seem dumb, but a 2D grid as a template is actually a surprisingly nice starting point for a lot of computing tasks and layouts. In terms of approachability, it is much easier to modify an existing template than it is to start with a blank canvas and create entirely new content. A blank canvas requires that the user have a vision of what they want to create, which they execute on by understanding the means of abstraction and means of combination. In comparison, the ‘modify a template’ mode of spreadsheets lets the user get away with just reacting to what’s on the screen. Bret Victor talks about some of this in Learnable Programming. I won’t argue here that one modality is inherently better than the other, but part of the appeal of spreadsheets is they do support the ‘create by reacting’ modality better than traditional programming.

makes a distinction for Frames (statements) and Slots (expressions). Slots are more free-form, but htere's still some structure here

> Isn't this just structured editing all over again? Didn't we abandon that in the 80s/90s? The ideas are similar to structured editing. Structured editing wasn't actually a bad idea, it was just poorly executed. In the intervening 25+ years, computing has gained advanced display/GUI capabilities, and we've learnt a lot about the usability of software. So you can think of this as a fresh attempt at structured editing. And really, this isn't the first attempt; Scratch and similar languages have already showed that these kinds of ideas can work.

scratch https://scratch.mit.edu/

MPS https://www.youtube.com/watch?v=PPU99grx28E

state machine language

Things that are cool about MPS

so many things

the "alt+enter" menu w/ autocomplete for minor refactorings

the way that not all information is represented in the text representation -> there are side panes that show more information and are also editable.

thisi is like the DOM inspector in Chrome, where you see the dom nodes, and then also have the style editor

I'm not 100% sure that this is good (wondering what things should be hidden by default but editable upon "unspection"), but it seems like a powerful concept

:i: this could be super great for tests! You focus a method, and if there's an associated test then it gets shown off in a side pane or something.

DSL editors for making the DSLs

Cedalion https://cloudalion.org/blog/

https://www.youtube.com/watch?v=Lb3x5lKeIfA

Eclipse plugin

interesting structure editor

This is super fascinating

uses predicate logic

Mixed Structured Editors

the creator: https://www.facebook.com/antonin.hildebrand?fref=ufi

embedded in atom!

also has strong "literate programming" feels

not touched in a year

inspired by "Flense" https://github.com/mkremins/flense

doesn't appear to be much to see there...

does a lot of work to maintain formatting stuff, has a bunch of shortcuts for structural stuff

maybe look to it for ideas on what transformations to do?

or definitely if I were gonna to something w/ haskell

interesting compromise, very lisp-specific

you're editing raw text, but parinfer does lots of auto-editing to ~ensure syntax consistency

editing commands

wrap current thing in ( or "

delete a synatic atom

slurp + barf => bring sibling atoms into an s-exp (or move them out)

replace outer s-exp w/ current s-exp

split / join s-exps

take current s-exp, wrap it around the enclosing s-exp

movement

to end of enclosing s-exp

to start of enclosing s-exp

https://www.youtube.com/watch?v=dYbxvRLpEUY

very similar to iPython notebooks

but the code is a hybrid structured editor, where the block-level stuff is structured, but the code is largely loose

the `inline console` is interesting though - it's a blob of GUI in the middle of loose text

yeah, so you can insert arbitrary "visual" stuff at any point in your loose code. Super cool

e.g. visual tables can be embedded as a variable initializer

:!: cool ideas of "what visual things can we use that are better representations of coding construct than a pretty-printed AST"

"Visual elements" / notebook

2015

not structured - still text

BUT includes graphical elements via CodeMirror plugins; can replace some swaths of text with a graphical, interactable representation

References

Barista : 2006

"Design Principles for the Enganced Representation : 1986

http://www.diku.dk/OLD/undervisning/2001f/f01.639/baecker.pdf

Experiments in Code Typography : 2014

http://web.archive.org/web/20160513144534/http://research.microsoft.com/en-us/projects/liveprogramming/typography.aspx

Main thoughts

blocks w/ left borders

still need parens for precedence, function calls

pseudo-ligatures are fun

:!: digit suffixes are subscript!

hmmm snake_case underscores are rendered as gray squares... weird

the "@" prefix anywhere means "log this"

metatext == tooltipy things below warnings, errors, or to log values

“the most effective debugging tool is still careful thought, coupled with judiciously placed print statements”

Expressive programs through presentation extension : 2007

http://www.cs.ubc.ca/~ade/research/ade-aosd.07.pdf

render a visualization of a finite automaton

haskell IDE http://haskellformac.com/

looks a ton like playgrounds (e.g. ipython notebook, lighttable) for haskell

light table

inspiration post http://www.chris-granger.com/2013/01/24/the-ide-as-data/

https://www.youtube.com/watch?v=V1Eu9vZaDYw

Getting away from ASCII-in-files

Eve http://witheve.com/

new language

literate programming! So you write blocks of text & blocks of code

a table of contents shows up in the left bar, based on headings & subheadings in your "documents"

fascinating idea for code organizaton.

You can check/uncheck items from the sidebar to show/hide sections of a given document.

a document === a program

if you check/uncheck a heading, all subheadings under it are also shown/hidden

super interesting ideas

Code execution

is order independent (due to the language design)

you can also enable/disable code snippets

Good parser errors

magic wand mode

"magic wand mode" where you can click on a rendered HTML element and see information about it

"An IDE like Medium, not VIM"

inline visualizations

Conception-go https://github.com/shurcooL/Conception-go

last commit Oct 2016

Conception https://github.com/shurcooL/Conception#demonstration

this example has structured text as well tho

this looks suuuuper cool. Would love a view like this for notablemind

interesting "canvas-like" approach to organization

contents of "code" blocks are raw text

BUT has "flow-based" programming cool stuff

also gui elements

leo editor http://leoeditor.com/

blog post about http://markdblackwell.blogspot.com/2011/07/installing-leo-outlining-editor-on.html

HN https://news.ycombinator.com/item?id=7843907

> The other problem is that it's not Vim. I also have this problem when trying out any other text editor. It's actually quite annoying because every other text editor I try is often much better than Vim at everything it does except editing text.

The time is ripe for a tool that integrates knowledge management and development with this "linked outline" structure; it's an upgrade over the classical folder-based storage of files.

There have been previous attempts to create integrated editors for semi-structured information both from the software (Code Bubbles) and documentation (Haystack project, Chandler) perspectives. Machines are now powerful enough for them to become useful and responsive (as these environments consume huge amounts of memory).

For such a tool to become widespread though, it will need to be based on user-friendly design, and be able to share content on the web. Evernote and Workflowy come to mind as tools with those properties, but they don't handle code execution; and reactive, live programming tools like jsfiddle don't allow for outline-like structuring. It would be great if such a tool was also Open Source, but that's unfortunately not a pre-requisite for success; I imagine Google or Apple will be the first to build such development environment, or to buy a start-up that build it and turn it into an standard.

:?!: aha notablemind!

I broadly speaking applaud the idea of breaking code into code-units which are independent of a specific file hierarchy and tagged with meta data; then reassembling them as a pre-compile / pre-run step.

The way it does that is by making 'clones'. So for example, if you have a long program that you find a bug in then you take the node with the buggy code (usually a few lines, maybe 10's of lines) and you 'clone' that node to the spot where you have your bug report or list of tickets or whatever. You then describe the bug, the fix and modify the code (which will modify the original code as well), or you modify the original code leaving the clone as a 'living pointer' to the code to document the location where the bug was found. You add the unit test as another node right where the bug report lives. The 'thin' model (where you import external files without actually having them present in your outline) is a variation on this theme, another way of doing it is to have the code present in the outline itself and then to export the code whenever the document gets saved. Both methods have their pros and cons. The biggest con in my opinion is that leo use is not widespread enough that you can expect to collaborate with someone else like this. That means that if you post your project on github or if you share the code with a fellow coder that all that Leo mark-up is wasted. This also likely does not play nicely with version control but I haven't tried that particular scenario myself (I just dump the whole tree in git or subversion and I work on most of this stuff on my own anyway).

SmallTalk

smalltalk image is a serialization of the whole system - all objects, data, etc

Notablemind stuff

symlinks

tags should mirror

source should mirror

Sources

umm idk

go through the whole db & assign numbers to each source (rebuild dynamically) in depth-first, preorder traversal

so maybe have a source be a node type (not a "belowbody"),

hmmmm although I can just as well get the belowbody stuff going.

and then symlinking would render great

but then the belowbody thing would just be a reference to the thing, with an optional page number / hour:minute / whatever

My Thoughts & Writings

Things I'm going to look at:

`gofmt`, `reasonfmt`, myntax --> maybe starting from a perspective where "we're standardizing the serialization format to remove as much arbitrary formatting as possible, so that pretty printing becomse really easy"

Structured editing vs plain text from a UI perspective

I think modal structured editing is the grail

arguments for†

arguments against

can't do arbitrary edits

what about preserving all the nonstandard formatting? ans: don't do it

What can visual elements get you? (and visual elements will be easier to do in a structured environment)

moonshine

maybe also the bret victor stuff?

... other notebooky stuff

A different way of displaying things (not just methods in a column, ordered somewhat arbitrarily)

eve

leo?

Conception

my ideas

What about moving away from ASCII on disk?

Keywords

structured editor

syntax-directed editor

projectional editor

semantic editor

maybe semantic-oriented programming?

https://en.wikipedia.org/wiki/Semantic-oriented_programming

195

Actual papers

Paywalled :(

Structured Editor Support for Modularity and Data Abstraction http://dl.acm.org/citation.cfm?id=17919.806835

http://ieeexplore.ieee.org/iel5/2225/361/00006888.pdf

170

Read

A Structure Editor for the Program Composing Assistant http://www.doiserbia.nb.rs/img/doi/1820-0214/2006/1820-02140601065S.pdf

2006

Problems w/ past structure editors

usual fix for this is to do a hybrid approach, where unstructured text is added and then parsed

and you switch between the two edit modes

references to other thigns

Mentor and Centaur [5] generate a structure editor from a format definition

Synthesizer Generator [28] cornell

5, 18, 28, 14, 23, 22

ProCompass (their thing)

Actions

ordered_list

{"id":"umt8asi61nmxrliys22kiyoe7cxhn2u3","created":1479445124199,"modified":1479445124199,"collapsed":true,"content":"move though structure","type":"ordered_list"}

ordered_list

{"id":"f5udhjbmyzx3pd6wviinjz50alkbgasb","created":1479445132767,"modified":1479445132767,"collapsed":true,"content":"add item before/after","type":"ordered_list"}

ordered_list

{"id":"wgf7fzzzqw3qlpy6n5tuovx5xb4srr7e","created":1479445138446,"modified":1479445138446,"collapsed":true,"content":"modify current node","type":"ordered_list"}

ordered_list

{"id":"fbke2qqvybf7akoawtvh9kq32ikke075","created":1479445143247,"modified":1479445143247,"collapsed":true,"content":"remove current node","type":"ordered_list"}

4 ordered_list

{"id":"6vupoxo45n2t77ybxzx1w9x1zyq5ert7","created":1479445146246,"modified":1479445146246,"collapsed":false,"content":"refactor current node","type":"ordered_list"}

change if to while

encapsulate a set of statements into a fucntion body

split function into blocks

copy / paste

context - dependent > the clipboard contents are truncated to the largest appropriate subtree that could be inserted at the current point

:!: also allow selecting a subset of the statements in a block to paste, for example

a "template", such as `int a = 0`, w/ three possible holes `? ? = ?`, and you replace the `?` with something

Citrus: A Language and Toolkit for Simplifying the Creation of Structured Editors for Code and Data http://repository.cmu.edu/cgi/viewcontent.cgi?article=1177&context=hcii

2005

huh, this is a toolkit for creating structured editors

VERY gui, like Visual Basic style. not really my jam?

but interesting in thinking outside of the mostly-text box

:!: thinking about a graph editor being a structure editor...

modeless structure editing http://www.cs.ox.ac.uk/bernard.sufrin/edit.pdf

mostly talking about how to enter an expression fluidly e.g. `1 + 2 * 3` in left-to-right, without any fanciness

example code is in haskell

Structure Editors – Old Hat or Future Vision? https://www.fbi.h-da.de/fileadmin/personal/b.humm/Publikationen/Gomolka_Humm_-_Structure_Editors__Springer_ENASE_.pdf

Made a structure editor for lisp

had people use it, conducted surveys

people prefer the structured editor, but "objective improvements are measureable, yet not significant"

:?!: "What the programmer thinks is what they see in the editor"

"We analyze the requirements of a usable structure editor"

Principles

2 ordered_list

{"id":"xns1ct4smbs26hxqci1mchu8g8ew8y5r","created":1479446770839,"modified":1479446770839,"collapsed":false,"content":"Focus on the net code (?)","type":"ordered_list"}

don't display the code in a way that's hard to read / understand

4 ordered_list

{"id":"61ypzjwlkppuccdzrw9mhiynm08bvyud","created":1479446776367,"modified":1479446776367,"collapsed":false,"content":"Do not restrain the programmer","type":"ordered_list"}

some [1,2] prevent the creation of syntax errors

"This had the effect that simple operations which change the structure of the program became quite complex, e.g. removing a parenthesis and inserting it somewhere else"

:!: will have to address this in my stuff

4 ordered_list

{"id":"ipzzy7cnt0aqo7pm48pzek7oh093folm","created":1479446801050,"modified":1479446804386,"collapsed":false,"content":"Keep the layout compact","type":"ordered_list"}

make reading & understanding the code smooth

"should be as compact as the plain text representation"

:t: dunno if I'm totally on board, now that screens are pretty big

2 ordered_list

{"id":"onclvgk2ql9i8i0fs1fbfivmrdzsm3n4","created":1479446892158,"modified":1479446892158,"collapsed":false,"content":"Keep common look and feel","type":"ordered_list"}

as similar as possible to widely-used editors

2 ordered_list

{"id":"qje7pjno0z4q38rstsljpz823i93lof0","created":1479446946709,"modified":1479446946709,"collapsed":false,"content":"Do not introduce new dependencies","type":"ordered_list"}

"should not necessitate changes to the programming language or the way programs are stored"

2 ordered_list

{"id":"5walen8i0706k6h25cji6hfmiymtwbzs","created":1479446952061,"modified":1479446952061,"collapsed":false,"content":"Make the layout configurable","type":"ordered_list"}

colors, etc.

3 ordered_list

{"id":"2wjlnnqv61e28xhupa4cofeo2du59jug","created":1479446957700,"modified":1479446957700,"collapsed":false,"content":"Leave the choice to the programmer","type":"ordered_list"}

"some programming tasts might be easier to achieve w/ a simple SE, an advanced SE, or a textual editor. Should be able to swap between editors & editor modes"

I also want to disagree with this - I think text should be ditched completely

Related work

Subtext!

re "A Structure Editor for C#" [18]

programmer is required to change the way they type (`{` etc aren't typed at all, and aren't displayed)

:?!: Our philosophy is that the programmer may type exactly the same code with the textual and structural editor in order to minimize the learning curve and to easily switch between editors

LOPs, projecting editors...

structured editors: old hat or future vision https://books.google.com/books?id=yj66BQAAQBAJ&pg=PA93&lpg=PA93&dq=new+programming+language+structured+editor&source=bl&ots=aTc_2-GEaI&sig=CD_gIGKBRAYVSJHSUqgRveFguzE&hl=en&sa=X&ved=0ahUKEwjdndrEka_QAhXHylQKHQFsCOw4ChDoAQgnMAI#v=onepage&q=new%20programming%20language%20structured%20editor&f=false

kirill's PhD thesis http://www.guilabs.net/

can go pretty minimal

His "Diplom" 132 pages http://www.osenkov.com/diplom/contents/1/4/

http://www.osenkov.com/diplom/KirillOsenkovDiplom.pdf

Introduction

Principles of structured editors

Atomicity

preserve the AST

atom changes that preserve language invariants

Correctness

preserve syntactic / AST structure correctness

Usability

"can reduce the number of primitive user input operations (mouse clicks, key strokes)"

don't have to worry about braces, code is formatted automatically

"an intelligent scrollbar" - sounds like Sublimes 1000 foot view... not super tied to SEs

"breadcrumb" showing the lineage of parent AST constructs

hmm might be interesting? IntelliJ does this for the package path

"key stroke prediction based on statistics"

Presentation

easily skinnable

"preserving a team's guidelines becomes a snap"

in fact, I'd say they become irrelevant :P

the possibility to collapse everything (well code folding is old hat)

:!: this is a kye thing

Extensibility

macros!

Implementation

could really simplify the implementation of many components

code completion

refactoring

debugging

edit & continue

eliminating the need for a background compiler

:t: but you still need a type checker? which could potentially be expensive

Performance

we can expect perf to be better? (but I think type inference is much more expensive than parsing...)

Storage and Version Control

changes could be stored & registered at the level of mutations

the code being edited could be a database repository on a possibly remote server

could allow several people to update the same code @ the same time

lots of merge conflicts disappear

all code checked in will be at least syntactically correct (and type correct too if that's integrated into your editor system)

Static analysis & Source code querying

Help w/ learning the language

an SE is more explicit about the language constructs being entered.

ppl don't have to learn the textual syntax in addition to the higher-level representation

Disadvantages & possible difficulties

Usability

must be able to just use keyboard

keypresses must not be much greater

consistency is important

Lack of familiarity

text editors are all alike, and so have low barrier of movement between them

Lack of flexibility

hmmm interesting claim

that structured editors, in order to be ideal, would want to relax some strictness constraints to temporarily allow syntactically / semantically incorrect programs?

not sure I agree

"The editor shouldn't stand in the way"

IDE Dependency

plain text is portable

don't lock people in to your specific tool

could have the option of storing source code to plain text files

or the storage format could be standardized (just like a programming language syntax is standardized)

:?!: Beside standardizing programming languages of the future, it will probably make sense to simultaneously standartize the structured storage/representation format for programs in that language.

Preserving source code formatting

I actually want to ditch custom formatting entirely :D long live the pretty printer

Standardizing difficulties

creating a standard sounds like it would be crazy hard

I think this might be assume more needs to be standardized than would actually be the case though...

Existing research

Problems w/ building structured editors

the complexity of making a parse tree interactive

a fairly complex framework of visual controls is necessary

Intentional Programming

book "Generative Programming", chapter 11

Functionality of the structured editor

:!: :!: ah, this one is hybrid. statements, method parameters are just plain text :(

I'm suddenly much less interested

Architecture

undo/redo

:t: I think I want function-level undo/redo!

Blocks

Implementation of the functionality

Implementing the C# editor

Integrating into sharpdevelop

Summary

https://blogs.msdn.microsoft.com/kirillosenkov/2009/09/09/first-videos-of-the-structured-editor-prototype/

In process TODO finish this

(in process of reading) "LORAX" Speaking for the Trees: a New (Old) Approach to Languages and Syntax http://ecee.colorado.edu/~siek/moss_msthesis.pdf

CURRENT PAGE: 18

2004

References

Charles Simonyi's Intentional Programming from the 1990s

Lang provides an interesting perspective [33]

The Fortress Language [2] [43]

:?!: "The limitations of parsers make languages difficult to extend and severly constrain the choice of notation

:?!: any class of structured documents, (recipes, essays, math problems) could be represented with a language defining the required elements and their relationships to each other

:t: think about this

ooh I like this figure

:!: "It's no longer possible for the programming to *read* the program one way while the parser disagrees"

"Syntax Directed Editor"

The ABC structure editor. Structure-based editing for the ABC programming environment http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.694.3304&rep=rep1&type=pdf

design and implementation of syntax directed editor http://www.dtic.mil/dtic/tr/fulltext/u2/a212085.pdf 1989

A small contribution to editing with a syntax directed editor http://dl.acm.org/citation.cfm?id=808242 1984

Syntax directed program editing http://onlinelibrary.wiley.com/doi/10.1002/spe.4380130507/abstract 1983

A relational program for a syntax directed editor https://archive.org/details/relationalprogra00maclpdf 1982

On the usefulness of syntax directed editors http://bat8.inria.fr/~lang/papers/trondheim86/usefulness-syntax-directed-editors-19860616-18.pdf ~1980s

towards user-friendly projectional editors http://mbeddr.com/files/projectionalEditing-sle2014.pdf

## People who are interested in this kind of thing

https://eev.ee/blog/2016/12/01/lets-stop-copying-c/

https://eev.ee/blog/2015/02/28/sylph-the-programming-language-i-want/

Big list at the end of this: http://web.archive.org/web/20070621162318/http://mindprod.com/projects/scid.html

Joshondesign - josh marinacci (sacred cows)

Jake Brownson https://twitter.com/jakebrownson

from "prune" post

the `plastic` and `east-west` folks

Joel Burget

from the "general purpose tree editor" post

https://github.com/invaliduser

https://pcmonk.wordpress.com

Rules

before you talk about your cool new editor/IDE idea, spend some time with intelliJ. Also, spend some time with MPS

483

Categories of things

365

Full Structured Editors

Pretty developed?

lots of usability stuff, but lots of cool things

type inference & display

"proportional font" is not something I anticipated liking, but maybe?

http://kevinmahoney.co.uk/articles/structural-editor-prototype/

Screencast https://youtu.be/shLQw_ivtfw (2:25)

https://www.facebook.com/notes/kent-beck/prune-a-code-editor-that-is-not-a-text-editor/1012061842160013/

quantifiable goals

fewer keystrokes

I don't think this is super useful

fewer errors

100%

greater overall efficiency

? how to measure?

[I would add]

better navigation

better understanding / reading of codebase

Tree Transformations!

"Wrap" a statement in an if

"Unwrap"

create, delete, reorder nodes

various stuffs

TBD Node - the "?" waiting to be filled in node

"the editor should allow the user to build a tree by introducing nodes in any order"

dunno what this means

"A hundred or so transformations suffice for editing JavaScript"

typeahead for it

they say not having parens reduces keystrokes, but I think that's actually not a super valuable goal

"validate that reducing the keystroke count was possible"

ummm yeah I really think this is a red herring

haha "programmers don't spend that much time manipulating programs copared to all the other things they do"

Learnings

tree transformations can work

eliminating the text editor, and just dogfooding, helped :P

yay formatting is a huge waste, don't look back

Future

target a tablet

:-1:

use a declarative language to define transformations

:t: hmmm interesting to think about

use a predictive parser :+1:

use jetbrains :/ eh

implement macros :+1: :+1:

let programmers implement their own sequence of transformations

reuse the transformations.

It seems like it should be possible to write a version control system that merges streams of transformations instead of textual diffs, potentially reducing the number of merge conflicts.

consider using machine learning to predict which transformation will come next :+1:

https://i.imgur.com/wvcduDk.png

this is a super good comment

the structure editor has to be really clearly beneficial for refactoring, reading code

structure editors allow more visualizations of the code! which would be a huge "a-ha" for people I think

yeah! emacs and vim are approximating this, but think if that was the full mode all the time!

I wonder if there actually is research showing this?

:!: another thing -> having the key strokes be uniform across different languages

which I think they really would be transferrable

looks pretty mouse-driven :( so not a super great interface

looks like haskell? but maybe written in ocaml? (based on the "ocaml structure editor toolkit")

oh wait - it's a custom language looks like. interesting

lots of tutorial videos

https://www.facebook.com/supereasy?fref=ufi

https://www.youtube.com/watch?v=w5-g0Hps6bA&feature=youtu.be

TODO read more lambda the ultimate

custom editor renderer using webgl apparently?

uses standard file organization though

collapsing code zooms it out

does some input restriction - space does nothing, can't add a binop in an object key

uses CodeMirror (or ACE), and so text is still the fundamental construct, but editing is completely controlled so it might as well be full

alt+arrows for navigation between atoms n stuff

cmd+arrow moves an atom around, or for nagivating within an atom

https://www.youtube.com/watch?v=HnZipJOan54

https://github.com/Cirru/stack-editor

Clouditor https://github.com/Cirru/clouditor/

https://github.com/Cirru/cirru-editor

Structur-ed

Blog about http://programmingmusings.blogspot.com/2012/11/projectional-editor.html

This is the one who made (is making?) `projecturEd`

hmmm

"a text editor is not cognizant of the edited data structure, because the actual meaning is hidden in the users mind"

Actually, I think the reason is that "the text will get parsed", and editing happens on the level of characters, and not on the level of the structured that the compiler will deal with.

It's called projectional editor, because it **provides its editing capabilities using bidirectional multistage projections between problem domains.**

fancy

huh, this is something I don't agree with. I wonder what the point is

:?: I would love to ask this person about the "we should allow syntax errors" bit

:!: Examples of projections:

filtering - it may be used to focus only some parts of the document while the rest is hidden (e.g. show the chapter titles only from a text document, show some elements from an XML document, etc.)

ordering - it may be used to sort the content (e.g. sort the functions in alphabetical order in Java code document, sort the calendar events in chronological order, etc.)

grouping - it may be used to arrange the content into groups (e.g. group the rows of a table according to the value in the cells of the first column, etc.)

more projection example stuff

text - stylized text similar to word processing documents

table - two dimensional arrangements

tree - collapsible hierarchical drawings

graph - drawings with nodes and edges

hmmmmm so "projectional editor is really just a generalized REPL" hmmmm :/

**define domain**: data structures of documents, selections and operations that belong to a problem domain

:!: example domains

data structures - boolean, integer, number, string, pair, tuple, list, tree, graph, set, map, etc.

data formats - XML, JSON, ASN.1, etc.

programming languages - C code, Java code, Lisp code, etc.

text related - paragraphs, styled text, word processing with chapters, spreadsheet, presentation, graphics, etc.

databases - relational data, object oriented data, etc.

**define document data structure** it describes the possible states of domain specific documents. Here are some document data structure examples:

integer domain - an integer consists of a sequence of bits

string domain - a string consists of a sequence of characters

list domain - a list consists of a sequence of arbitrary elements

XML domain - an XML element consists of a list of XML attributes and a list of XML child elements, an XML attribute consists of a name string and a value string, etc.

graphics domain - a point consists of a 2D coordinate and a color, a line segment consists of two 2D coordinates, a color and a thickness, etc.

ooooh this is getting really interesting. trying to lay down the really general things about an "editor"

**selections**

string domain - a character position selection consists of a string reference and an integer in the range [0, length]

XML domain - an element range selection consists of a parent element reference and two integers in the range [0, child count)

Java code domain - a method selection consists of a method reference

operations

integer domain - bit negation operation consists of a bit selection

string domain - delete character operation consists of a character selection

list domain - replace element range operation consists of an element range selection and a replacement list document

primitive projection - directly between 2 problem domains

styled string to graphics - transforms a styled string to graphics document directly related to API calls

tree to string - transforms a tree of nodes to a flat string using delimiters and separators

XML to tree - transforms an XML document to a tree with attributes and elements being nodes

mk, so this is a really interesting theory of projectional editors.

I certainly don't think I'll go this direction (with the focus of converting between all these different projection domains), because I think the funtamental benefit will come from just treating our code as a structure instead of a lump of text. But super interesting anyway.

written in common-lisp

last commit in Feb (9 months ago)

Shows many different languages interleaved with each other

"Priojections" different reversable presentations of the data

https://github.com/projectured/projectured

http://projectured.org/

last updated: 2012

https://github.com/mthiede/concrete

BUT the author commented on a github issue a day ago, so is still there

Can create custom html+css templates to display a given syntax node. super cool

same editing commands apply

editing keyboard experience seems very different from text editors -- have to first define the "binop" then the first el, then the second.

http://vimeo.com/9164866

InfoQ article https://www.infoq.com/articles/dsl-concrete-editor

interesting display choices (still all text though)

haskell-like (hmm it does look like it's a new lang)

rename is supported

Summary

No syntax errors or name errors

Type errors are localized - static typing becomes friendly rather than scary

Type inference works even in intermediate states

Type driven editing reduces keystrokes and cognitive load

Lamdu HN https://news.ycombinator.com/item?id=6964369

Chris Granger on the problems presented to structured editors

For those new to this world and wondering why this stuff doesn't seem to exist, one of the biggest problems with projectional editors is handling the translation problem.

How do you reconcile changes in your representation with changes in the underlying code?

Can you reliably parse handwritten code into your AST representation write it back and so on without any loss?

What happens with handwritten styles that maybe don't fit into the projection's way of viewing the world?

What if I know a better way to output the AST than you?

It's also particularly difficult dealing with change over time since there are no true unique identifiers for bits of code.

:!: so make sure that flow is not compromised

:t: hmm so this is "translating multiple languages to the same AST representation"

:t: this just sounds like an IDE

this 2004 post by oliver steele remains one of the best things i've read on the topic: http://www.osteele.com/posts/2004/11/ides key quote: "In fact, the most powerful languages may initially have the least powerful tool support. The reason for this is that the language developer, like the language adopter, has to make a choice: whether to dedicate limited development resources towards language features, or towards tool support."

:t: hmmmmmmm I feel like this might be a false dichotomy

:!: oooohh integrated versioning! I should check this out more

:!: moving from the way himans think? :D what does that even mean, do we naturally think in strings of code?

Granted, if a human wants to describe a physical process, they will use procedural language. But computers are primarily about information, and we think about information in terms of relationships. That's exactly what FP is about: expressing computation in terms of relationships.

:t: oooh I really like this framing

:!: hahah actually classical music is awesome

136

https://news.ycombinator.com/item?id=9512955

for me good IDE feels like semantic editor. I'm inclined to believe that text based editor can have all the good features of semantic editor and avoid most of the bad ones.

:t: gonna address this directly

I suspect that what he has in mind is that any value within the Unison language can appear on any Unison node, transparently. Instead of picking out exactly which fields you need and then creating new JSONObjects or protobufs for them, just send the whole variable over.

:!: ah the answer for this is probably type inference (ocaml style) where function types don't have to be declared ahead of time

also allowing return types to be errors (e.g. have an implicit `failwith "incomplete function"` at the end of the function)

:!: yeah that sounds a lot more annoying ; a usability problem

I'd say that users like constraints too

immutable data

VIM modes

:?!: got to show how "play" can happen in a structured editor

https://pchiusano.github.io/2014-09-30/punchcard-era.html

traditional programming is compile, fix compiler errors, repeat

with REPLs we gain some benefits back, where you can have a feedback look, a discussion w/ the env

but then you move to your file and it's ultimately separate -- even if you can do things like "try evaluating this snippet" from your text editor (emacs + slime)

constrain the editing UI to only allow the creation of programs that typecheck

Challenges of this

wouldn't have a "cursor" where you can add arbitrary characters

how do you respond to invalid input?

how to navigate around the document?

plain-text programming gives people a feeling of directness & control

Advantages of SDE

no parser to write

no tracking locations ( :t: not actually true, there are tree locations now)

trivilly ensure well-formedness

can render as stuff other than text

large-scale edits can be described as a set of refactoring combinators rather than manual text munging ( :| IDEs do this already to some extent)

usable by children & newcomers to the language! like bowling lanes with bumpers

:t: I would submit that *synax is not the hard part*

100

Blog posts

Concurrent Version control + editing

"Semantic Version Control"

Designing a fluent interface to a semantic editor http://unisonweb.org/2015-10-14/fluent-editing.html#post-start